perm filename RELIEV.TEX[LOT,JMC] blob sn#388456 filedate 1978-10-18 generic text, type C, neo UTF8
COMMENT āŠ—   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	\input basic
C00020 ENDMK
CāŠ—;
\input basic
\ctrline{RELIEVING THE LOAD ON LOTS}
\ctrline{by John McCarthy, Director of LOTS}
\vskip .5 cm
	It seems universally agreed that LOTS is overloaded, especially
at the ends of quarters, and this memo discusses various ways in which
the situation might be improved.

	1. An improvement is in the works.  It has been decided to
upgrade the processor from a 2050 to a 2060.  This upgrade, which
costs $\$$50,000 is expected sometime in Fall 1978.
Besides increasing the speed of the computer by 20 percent, it will
keep us up-to-date with D.E.C. software, and for technical reasons
is important in connection with the memory upgrade.

	It is considered very likely that increasing the memory from
512K words to 1024K words will substantially improve the performance
of the machine.  At least such effects were noted at the Artificial
Intelligence Laboratory and at SRI.  Therefore, it has been decided
to rent the increased memory for three months starting in Fall 1978
and to buy it if the expected improvement materializes.

	These improvements will bring the present LOTS computer system
up to its full potential performance in speed and response time.  Other
improvements, such as another tape unit, the DECNET inter-computer
communication facility, and more disk may also be desirable at some
time, but they won't contribute much to direct throughput.

	It is almost certain that the memory increase and the processor
upgrade will still leave LOTS with insufficient computer capacity.
Therefore, we continue with other ways of relieving the load.

	2. The most desirable improvement would be to replace the
computer by one that was four or five times as fast and cost no
more.  Then we could put on more terminals, and we would have a
substantially adequate facility.  By adequate, we mean that students
in courses would be able to come in during most of the day even
towards the end of the quarter and do class assignments of the
size now given without experiencing long waits for terminals or
very slow response.  By slow response, I mean that the delay
caused by the slowness of the computer is long compared to the
delay caused by the student's own thinking and typing.  Of course,
however much computing is available, there will be users who can
benefit from it.  After all, a class of 100 in aeronautics could
benefit from having every student to a parameter study of the
flow past a 3-dimensional trans-sonic airfoil, and a meteorology
class of 100 could benefit from having each student predict the
next days weather numerically.  Such computations are infeasible
today on even the largest machines.  However, LOTS is presently
overloaded in the sense that students wishing to write, edit, and
debug problems in simple programming languages meet with difficulty.
When we get enough computer capacity, we will be able to configure
the operating system so that the big users can compete with each other,
but the small users can compute freely without interference from
them.

	It is also reasonable to hope that such a computer will
allow us to make text preparation of reports, etc. rather freely
available --- again without interfering with programming courses
and getting reasonable service itself.  In my opinion, as soon as
LOTS gets its house in order, this should be the next big push
to use computers
to benefit education at Stanford.

	{\it Unfortunately, the aforementioned faster computer for the
same price doesn't exist}.  However, we have good assurance that
such a computer will be available in two or three years from D.E.C.,
our present supplier, and others.

	2. The second option is to buy another computer like the one
we have.  The cost would be about $\$$800,000 if we duplicate the
entire system.  It could be operated by adding two people to the
present LOTS staff of four.  The major objection to this course is that
it might preclude our getting an improved computer when one becomes
available.  The option can be studied further from various points
of view, but my impression is that Stanford will decide to wait.

	3. We can shed some of the present LOTS load back to SCIP.
First about 15 users out of 2500 used about 25 percent of the
computer time during the last week of September 1978 and the first
two weeks of October.  Some of them were finishing projects which
were intended to be done during the summer.  It seems likely that
getting these users to switch to SCIP will relieve the load on
LOTS.  I say ``seems likely'', because they may be squeezed out
by the Fall Quarter mob anyway, and it is not entirely certain
that the compute-intensive users burden LOTS more than input-output
intensive users.  Nevertheless, while it is not certain, it seems
probable that exiling them and other graduate student unsponsored
research users will cause relief.  They are also heavy
users of terminal time.  (Incidentally, these heavy users are
well distributed among engineering, social sciences and education,
etc.)  

	If they are booted off LOTS, they will presumably ask their
faculty advisers to get them money allocations for SCIP.  It may
turn out that some of them will not be well-loved enough by their
departments to get allocations adequate for what they want to do.
Some of them may survive as marginal users of LOTS.  Having exhausted
a standard quota of terminal time or compute time, they can get
more only during those hours of the day and times of the quarter
when they don't interfere with others.  The system already enforces
terminal time quotas and can be made to enforce compute quotas.

	4. SCIP has spare compute capacity and interactive capacity
during the wee small hours, and it has been proposed to off-load
some LOTS courses onto SCIP.  Here are some considerations.
Only in some courses is it feasible for some students to use
SCIP and others LOTS, because often the teaching material must
be specialized to the operating system, and necessary files
would have to be duplicated.  Splitting a course or giving students
options is most feasible in a project oriented course using a
language like FORTRAN that the student already knows and for
students who are already familiar with general computer use.
Otherwise, it is necessary to move the entire course.  If this means
that during the whole quarter, the whole class must use the wee
small hours, instructors may have difficulty deciding that
freely available after midnight computing during the whole
quarter is better than a 24 hour somewhat crowded machine during
the whole quarter with a real jam at the end of the quarter.  There
is no harm in offering the option, however.

	Terminals are an additional consideration.  Most SCIP connected
terminals belong to user groups and are unavailable at night.  However,
there are 17 public CRT terminals and 10 to 12 public hard copy
terminals at Pine hall and 3 more at Meyer and Terman.  This would
suffice for a considerable number of courses.  If it were necessary
to add additional terminals only for night use, there cost would
have to be charged against the time they were available.  Making
LOTS terminals usable on SCIP wouldn't solve anything, because the
number of LOTS terminals is related to LOTS's compute capacity,
so that when LOTS has spare terminals, it usually also has spare
compute capacity.  The best option would be simply to increase the
number of SCIP public terminals if needed.

	Every solution that involves using compute capacity that is
available only at certain hours faces the terminal problem unless
the students can use the same terminals ordinarily used by the
daytime users of the facility.  Besides the cost of the terminals
themselves, there is the much large cost of the space they occupy.
The problem is slightly relieved by the fact that a few students
own terminals and can use them by telephone from their rooms on
whatever computers are available to them.  While LOTS has done
nothing to provide such terminals, our 13 telephone lines are often
fully occupied at night.  In the future, this effect will be even
more important.  A public terminal room with dial-up terminals
might be quite useful in connection with a variety of computers.

	5. It has been proposed that LOTS be bought a share of the
Computer Science Department's proposed D.E.C. 2060 computer and that
it maintain the machine for the Department with two additional people,
perhaps including hardware maintenance.  Maintaining the machine
and sharing it are independent proposals, both are feasible, but
only the second is relevant here.  Sharing the machine is best 
accomplished by adding DECNET to both machines and increasing the
number of terminals at LOTS to correspond to the increased capacity.
Its usefulness depends on the fact that CSD usage will also be spread
through the 24 hours, so that the additional LOTS terminals can
get full use.  If this option is interesting, cost estimates can
be obtained.  Course use of the CSD computer using its own terminals
is limited by the fact that these terminals will be in CSD offices,
and there isn't space in the CSD semi-building for another terminal
room.  Again whole courses should be moved to that machine, and there
would be some advantage to making them CSD courses or at least
courses taught by other faculty, e.g. DSL, using the same machine.

	6. Before LOTS, student computing was done in batch mode
at SCIP.  A major advantage of LOTS is that it provides interactive
computing.  Most instructors have now used both modes of operation,
and it seems to me that any instructor who prefers batch on SCIP
should have that option.

	However, some of the requests for use of SCIP for courses
ask for interactive use.  SCIP's prices for interactive use have
been reduced, especially at night.  It may be that Stanford can
now afford considerable interactive use of SCIP in courses.

	My final recommendation is that Stanford use some combination
of the above ways of temporizing while it waits for the availability
of a higher performance LOTS type machine.

	The following important issues have not been discussed in
this memo: why Stanford should push for student text preparation
capability and what role LOTS might play, terminals in dormitories,
an improved terminal system, why LOTS needs another tape unit, and
the Advisory Committee suggestion that LOTS be put on a fee-for-service
basis.

	Finally, it should be remarked that the overloaded state
of LOTS appears differently to different people.  Many people
find it a minor annoyance, persist and achieve their goals.  Others
find the situation quite frustrating.  Students with class assignments
requiring the use of LOTS or some other computer probably
complete them as often as they complete any other kind of assignmed
work.  The degree of frustration depends on what the user is trying
to make the computer do, on the user's personality, and also on
how central his computer work is to his general purposes.  For
many purposes, any computer is of marginal value and proves
to be more trouble than it is worth.
For these reasons, volunteered complaints of individuals or
even representatives of groups have their main value in suggesting
issues that should be investigated.  Decisions should be based on
measurements and extensive surveys.  Both of these indicate that
LOTS is overloaded.
\par\vfill\end